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@ Method of Isolating and diagnosing problems In data communication networks 

@ The present method of isolating and diagnosing problems request 
in a data communication network simplifies the process greatly 
by permitting a system control operator (1) or control 
application program to issue generic, non-device-speciflc 
problem isolation, control or diagnostic commands (2) to the 
communication network (5) by Identifying the link and target 
node (7) for which problem isolation and diagnosis is required. 
The non-device-specific commands are received first at an 
intermediate translation facility (3) which retrieves communica- 
tion link physical configuration data (4) and identifies the 
physical components and characteristics thereof that make up 
that communication link to the identified target node (7). The 
translation facility (3) then issues one or more device -specific 
problem determination commands on the communication link 
directed toward said node. It receives one or more device-spe- 
cific responses from one or more physical devices in the 
communication link and, responsive thereto, either issues 
further device-specific commands on the communication link to 
complete the diagnosis or issues generic, non-device-specific 
problem identification results as responses to the initial 
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Description 

METHOD OF ISOLATING AND DIAGNOSING 

This Invention relates to data communication 
network management and particularly to a method 
and an apparatus that provide isolation, diagnosis 5 
and control of communication problems or faults In 
the communication link resources. 

Numerous prior network link management prob- 
lem diagnosis methods and devices exist In the field. 
These generally are designed in a manner specific to 10 
the particular physical devices that make up the data 
communication links. In telephone systems in 
general, loop back signals may be transmitted from a 
controlling node to the various elements making up 
the communication link to a target node, and signals 15 
may be propagated down the communication link to 
be looped back by devices in the line which are 
operating correctly and which can respond to the 
loop back commands to the control node. Such 
processes are, however, totally inappropriate when 20 
the data communication network devices operate 
under differing protocols, are supplied by different 
vendors and have differing diagnostic or data 
providing capabilities. 

More sophisticated techniques are also In exist- 25 
ence where the data communication network con- 
tains devices supplied by the vendors of the host 
data node or control node systems. For example, the 
IBM Corporation markets components for a data 
communication system including host system main- 3t? 
frame computers, operator control consoles and 
communication network control program applica- 
tions that can communicate with and diagnose 
problems occurring In a data communication net- 
work that Includes IBM supplied modems, multiplex- 35 
ers, switches and the like. However, these systems 
share a common system architecture and communi- 
cation protocol and are thus amenable to a single 
diagnostic application program and protocol. They 
avoid the difficulty encountered as mentioned 40 
above, with numerous protocols and numerous 
physical devices supplied by diverse vendors. Such 
uniform systems are. however, not often achieved 
and in many networks constructed by users and 
purchasers of various components, such uniformity 45 
cannot be brought about without major reinvest- 
ment. 

It is therefore desirable that some method and 
system apparatus be provided that Is capable of 
accommodating the more usually encountered data SO 
communication networks which are constructed of 
multiple layers of various vendors* physical devices 
having diverse capabilities and communication 
protocols. 

It is an object of this invention to provide an 55 
Improved method and apparatus for isolating and 
diagnosing problems In data communication net- 
works. It is further an object to provide an improved 
diagnostic system In which the controlling node may 
Issue generic problem determination requests to an 60 
intermediate translation facility having access to 
data concerning the physical configuration and 
characteristics of the network components which 



PROBLEMS IN DATA COMMUNICATION NETWORKS 

comprise a link to an identified target node experien- 
cing a problem, and which intermediate facility can 
translate the generic and non-device-specific re- 
quests for diagnoses Into device-specific com- 
mands addressed to particular devices in the link 
and which can receive from such devices specific 
responses which may be retranslated back into 
generic problem determination responses to the 
requesting host operator or control program. 

The foregoing and still other objects not specifi- 
cally enumerated are provided by the present 
Invention In an architecturally designed system 
utilizing a novel communications technique. The 
system comprises a host or operator that Is 
responsible for generating generic control or prob- 
lem determination diagnostic requests. These re- 
quests are issued in their generic form in a 
non-device-specific format. The data communica- 
tions system contains an intermediate control and 
translation facility that intercepts the generic prob- 
lem determination requests from the operator or 
user system. The translation facility has access to 
physical configuration data files that constitute a 
network map and contain information for each link 
under the translation control's responsibility. This 
identifies, for each physical device constituting each 
communication link within its purview, the salient 
characteristics thereof Including the. communica- 
tion protocol requirements, capabilities and physical 
location or addresses for each such device. The 
translation control facility accesses these data files 
for an identified target node and link in response to a 
generic request from the host operator or user 
system. It then Issues one or more device-specific 
addressed problem Isolation, determination or con- 
trol commands onto the communication link. It 
receives device-specific responses from devices 
which it Is capable of accessing utilizing the 
Information from the physical configuration data 
base. This intermediate translation and control 
facility then may issue stIU further commands to 
specific physical devices until the problem situation 
has been isolated and Identified (and perhaps 
resolved by Implementation of an avoidance tech- 
nique such as switching to another communication 
link) and It retranslates the results Into generic 
non-device-specific problem determination results 
which are responsive to the original generic request 
from the host operator or application. It transmits 
these non-device-specific generic responses back 
to the requester. The responses Identify the source 
of the problem and indicate to the system operator 
or control program which measures have been taken 
or need to be taken to recover from the problem 
situation. 

The Invention will be described with respect to a 
preferred embodiment thereof which Is further 
illustrated and described in the drawings In which : 
Figure 1 Illustrates a schematic data com- 
munication system or network constructed In 
accordance with the present Invention as a 
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preferred embodiment thereof. 

Figure 2 illustrates the conceptual definition 
of physical link connections and physical link 
connection segments as components linking a 
using node to a target node or station. 

Figure 3 Illustrates schematically the logical 
conception of a communications link together 
with the physical reality of a specific communi- 
cations link in its conceptual form. 

Figure 4 is a problem determination example 
flow chart showing how the Intermediate trans- 
lation facility organizes the diagnostic pro- 
cesses and communications with the various 
link components with one LCSM and static 
connections. 

Figure 5 illustrates a portion of another 
diagnostic flow chart example with one LCSM 
and dynamic and static connections. 

Figure 6 illustrates yet another diagnostic 
flow chart example with two LCSMs and 
dynamic and static connections. 

Figure 7 illustrates an example of nested or 
layered multiple intermediate control and diag- 
nostic facilities in a layered network. 

Figure 8 illustrates multiple diagnostic and 
control facilities interconnected in a peer net- 
work configuration. 

Figure 9 illustrates schematically a generic 
request or response message format. 
The present invention provides a method and 
apparatus for allowing a data communication system 
or network operator or even an automated applica- 
tions program running In the host or control system 
to provide problem determination and management 
in the physical computer data communications links 
and connections. The method devised does not 
require that the system operator "understand" the 
physical components that make up the communica- 
tion link connections In the system. By "under- 
stand", it is meant that neither the system physical 
component types or Identities that make up a given 
communications link nor the specific commands, 
formats or responses that the components are 
capable of receiving or providing need be known to 
the operator or to the diagnostic applications 
program. 

The invention is conceptually and schematically 
illustrated in Figure 1. 

By way of Introduction to some unique termino- 
logy and to provide an understanding of the basic 
concepts of the Invention as applied to this system. 
Figure 1 Illustrates a user system 1. The user 
system 1 is the communication system operator or 
application program which is the source of generic 
problem determination and control requests. The 
generic requests are issued as non-devlce-specific 
Inquiries or requests over a communication path 2 
that could be a tightly coupled on-site cable link 
between the control console or an internal link 
between the control program and an intermediate 
service system 3 or it could be a communications 
link to a remote service system. The interconnecting 
link is shown generally as 2 and carries generic, 
non-devlce-speclfic inquiries or requests and result- 
ing responses from the service system 3. 



Service system 3 provides an intermediate control 
and translation facility and will generally be in the 
form of a program which Is executed to provide 
specific diagnostic processes as will be described In 
5 greater detail later. The service system is associated 
with a physical network configuration data file or 
manager that contains, in effect, a network configu- 
ration map. This is shown as block 4. Block 4 
contains the associated particular device data 
10 indicating the physical connections making up 
various links under the purview of the sen^Ice system 
3, the specific physical de\dce Identities, capabilities 
for diagnoses, communication protocols and for- 
mats and the like. This information is used by the 
15 service system 3 to generate device-specific re- 
quests and Inquiries into the communication net- 
work shown as various logical links 5 In Figure 1. 
These are generally addressed, device-specific 
commands that are generated and sent to diagnose 
20 the condition of a given physical communication link 
by diagnosing Its component parts In serial fashion 
from the end nearest the service system 3. A 
particular using node A Is Identified as. numeral 6 
within the overall communications link 8 which links 
25 the using node 6 with a target station 7. Overall, the 
node 6, the station 7 and the interconnecting 
communication link may be comprised of many 
components and constitute a "target system" for 
which problem diagnosis and control Is desired in 
30 the context of the present invention. 

Specific names have been given to the user 
system, service system and target system in the 
context of this Invention. The architectural design of 
the preferred embodiment of the invention as shown 
35 in Figure 1 has components that will now be 
Identified In greater detail. The service system Is 
constituted by a Link Connection Subsystem Man- 
ager hereinafter LCSM. The LCSM 3 in Figure 1 has 
access to configuration data obtained and managed 
40 by another program or facility In files of Information 
identified as the Link Connection Configuration 
Manager (hereinafter LCCM) The physical link 
connection components linking a using node 6 to a 
target node 7 and which make up the communica- 
45 tions link 8 between the two are known as Link 
Connection Components (hereinafter LCCs). 

Figure 1 illustrates the basic scheme, architectural 
design and logical flow of the preferred embodiment 
of the invention. In general, the user system, I.e., the 
50 host system control operator or control program 
needs to be able to send diagnostic requests to and 
receive responses from the communications facility 
to get information about the logical link connec- 
tions 8 without having to "understand" what the 
55 specific physical link connection components may 
be. what their interconnection paths may be, or what 
their various requirements, capabilities and proto- 
cols may be. In the Invention, the service system, the 
LCSM 3, receives generic problem determination or 
60 control requests from the user system 1. In 
response. It accesses the configuration data base to 
determine the present physical configuration of the 
specific link to the target system node or station for 
which problem determination has been requested. 
65 The service system, the LCSM 3, does this by a 
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generic request to the LCCM 4. The service system 
then Is armed with a device-specific data and the 
physical network configuration and interconnection 
Identifications that show the physical components 
making up a given communications link. LCSM 3 Is 
then enabled to issue device-specific commands In 
series to the LCCs making up the given link for which 
problem determination is required. The LCSM 3 
generates appropriate device-specific diagnostic 
and control commands to be sent to the physical 
target system devices serially to analyze their 
condition and to analyze the data responses re- 
turned from the LCCs. In response to any device- 
specific replies, the LCSM 3 generates either 
additional inquiries and/or, finally, generates the 
response to the user system 1 in the form of a 
generic non-device-specific problem determination 
message. 

As alluded to earlier, target system link connec- 
tions may be made up of multiple layers, herein 
called link subsystems, comprising various types of 
physical devices, device capabilities, and communi- 
cation protocols all of which are usually provided by 
diverse vendors. As Information and data communl-- 
cation networks of the type shown in Rgure 1 are 
constructed by users, they generally grow to 
support multiple protocols Including IBM system 
standard SNA and non-SNA protocols. These sys- 
tems usually contain multiple logical networks and 
may incorporate one or more physical networks. The 
data communications networks so constructed not 
only provide for the transportation of data In the 
normal systems today, but they may also Include 
analog or voice information which has been suitably 
digitized for communications and control purposes. 
These factors all compound the problem of diag- 
f nosls for any specific problem Isolation In the 
network, and particularly for Isolating faulty compo- 
nents In a given link. The invention describes an 
architectural structure and system method of oper- 
ation that allows support of both SNA and non-SNA 
hierarchically nested or peer connected networks. 
The architectural structure design allows functions 
such as the service system function, the user 
system function or the target system function to be 
interconnected, distributed throughout the network 
in various components and/or nested In layered 
interconnections. The specific choice of placement 
for a given function within the structure is dependent 
upon the level of support, i.e., problem detection 
analysis or determination, that is to be implemented. 
The Invention provides a consistent view of the link 
connection subsystems that allows effective prob- 
lem determination and link fault recovery processes 
to be performed by the operator or control program 
for Individual link components without the control 
program or operator being required to know what 
the specific link components or their characteristics 
actually are. 

As noted above, the major problem with user 
constructed systems is that of providing effective 
problem determination In multi-layer, multi-vendor, 
multi-protocol communication networks. The end 
user usually Is the first person to notice that there is 
a problem somewhere In the network, but the user 



usually waits for a period of time before calling the 
network operator for assistance. The reaction times 
of the end user and of the system operator account 
for a large part of lost system availability. Once it has 
5 been determined that a problem does exist, then 
some^ form of problem determination procedure 
must be performed in order to detel-mlne which 
physical device Is at fault and what physical device 
recovery procedure should be employed to provide 

10 the fastest restoration of service to the end user. In 
the simplest form, this may be merely a matter of 
discovering which device is faulty so that It may be 
replaced or so that its particular vendor may be 
called for service. In the present day environment, 

75 these procedures are manually performed and may 
be disruptive to the communications link not only to 
the end user but to any Intermediate system 
components. 
The problem grows even more complex as 

20 communication network users migrate from separ- 
ate physical network for voice and data into 
integrated physical networks for handling both voice 
and data. The problem grows significantly more 
complex as users also add higher functional compo- 

25 nents such as Time Division Multiplexers, Statistical 
Multiplexers, Protocol Converters, Front End Line 
Switches and the like. These diverse physical 
components create their own complex sources of 
problems and compound the difficulty of isolating a 

30 fault within the communications link in which they 
are used. They also create additional layers of 
complexity in the network. Such physical devices 
and the resulting complex communications link may 
provide many misleading conclusions If the specific 

SS idiosyncracles of the various devices present In a 
given physical link are not taken into consideration 
during analysis of the failing conditions. In the 
architectural system shown In Figure 1, the LCSM 3 
implements a diagnostic process that allows sup- 

40 port of SNA and non-SNA hierarchical and peer 
connected networks. It allows functions to be 
distributed and/or nested within the network Itself 
and permits programs or system operators to 
access link subsystem physical data for performing 

45 problem determination and/or to effect operational 
changes. Each subsystem has its own LCSM 3 
responsible for the subsystem's unique problem 
determination and probable cause analyses for the 
physical devices constituting the subsystem. The 

50 knowledge of what the physical link configuration 
comprises gives to the LCSM-3 the ability to send 
diagnostic or control requests to other subsystem 
managers and also provides the operators access to 
all of the components In the link connection, 

55 Management of the link connection requires Its 
own hierarchical structure for commands and data 
flow. This structure is shown conceptually in Figure 
2. The physical link connection components 10 are 
the LCCs, LCC-1 through LCC-4, shown in Figure 2. 

60 Together, LCCs form physical link segments 9 
between each LCC and the next LCC, node or 
station. The segments 9 provide the overall physical 
link 8 connection between a using node 6 and a 
target station 7. The logical SNA view of the link 8 

55 does not always reflect the fact that physical and 
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hierarchical structural changes may occur or that 
various physical devices actually exist to make up 
the physical link segments 9. The logical structure 
utilized in the invention is shown in Figure 2, The 
actual physical link 8 is the connection of compo- 
nents that a user has assembled forming the logical 
link between two stations 6 and 7. In Figure 2, the 
using node A and station B couid be SNA or 
non-SNA nodes. Both node A and station B contain 
a station that wishes to communicate to the other 
through the link connection 8. The link connection 8 
is composed of some arbitrary number of physical 
connection components. Each of the physical 
components 10 is referred to as a Link Connection 
Component LCC. Each LCC receives signals on its 
physical Interconnection to the link and then passes 
them to another LCC or eventually to a node. The 
LCC is the smallest addressable element In the link 
connection 8. It can sometimes be addressed 
through a data link protocol of general usage or may 
require a specialized format. The addressability 
allows the subsystem manager LCSM 3 in Figure 1 to 
address each LCC 10 using the correct protocol and 
physical capabilities that it has learned from the data 
stored in the LCCM 4. The LCSM may then send 
requests for data to specific LCCs 10 in a format or 
protocol understandable to them. It can then receive 
the responses from the LCCs 10 and interpret them. 

The communication path segment connecting two 
LCCs 10 is identified as a link segment 9 In Figure 2. 
Each link segment 9 is a portion of a communication 
path that may include copper wire, coaxial cable, 
optical fiber, microwave links or other satellite or 
radio communication components. In addition, a link 
segment 9 may contain even other LCCs 10 and 
other link segments 9. The definition thus given Is 
generic. For example, in Figure 2, there Is a link 
segment between LCC-1 and LCC~3 that contains 
two smaller segments interconnecting LCC-1 to 
LCC-2 and LCC-2 to LCC-3. Each LCC reports to an 
assigned link connection subsystem manager, 
LCSM 3. An LCSM 3 is thus responsible for one or 
more specific LCCs and therefore is in control of the 
link segments there-between. An LCSM 3 may 
address its assigned collection of link connection 
components 10 and Is responsible for the manage- 
ment of the components themselves. The collection 
of components addressed by an LCSM 3 is referred 
to as the link subsystem for logical analysis. A 
detailed description of a preferred embodiment 
together with the steps utilized in the method of 
operation of preferred embodiment will now be given 
together with detailed descriptions of the various 
processes employed and an identification of which 
devices within the physical network they are em- 
ployed. The functions performed by each process in 
the link connection that services the operation of the 
link and which aid In link problem determination and 
eventual recovery will be de scribed now. 

The specific components that are described 
include the nodes A and B which use the link, each 
of the LCCs 10 that make up the link interconnec- 
tions, the LCSM 3 and the LCCM 4. 

A typical using node 6 as shown in Figure 1 may 
be a communications controller or a communica- 



tions system having an integrated communications 
adapter. Either type of device incorporates program 
controlled self-diagnostic capabilities for determin- 
ing whether the node itself Is the cause of a problem 
5 or whether the problem is In the communications 
link attached to It. A node 6 Is assigned the 
responsibility for detecting link connection prob- 
lems. This is usually accomplished by inference from 
the node 6's inability to send or receive or by the 
10 detection of an extensive number of retransmissions 
being required on that link. The using node 6 has two 
functions to perform In the event a problem Is 
detected. First, node 6 must perform an elementary 
probable cause analysis of each problem to deter- 
15 mine whether the problem is due to a failure in the 
node itself or whether it lies in the link connection. 
\Nhen a failure Is discovered within the node itself, 
then the node runs its own intemal diagnostic 
routines to isolate the problem for reporting. An 
20 improperly functioning communications adapter. I.e.. 
a line driver, internal modem or the like, might be 
found in such a test. When the problem Is not within 
the node 6 Itself, It Is assumed to lie somewhere 
within the link connection components attached to 
25 the node. The node then reports this link connection 
failure to the link connection subsystem manager, 
LCSM 3. Systems and devices of this type that 
comprise a using node 6 as just discussed are in 
common usage today. An IBM 3725 communications 
30 controller Is a typical example of a system that Is 
capable of diagnosing faults In itself and/or of 
identifying the fact that the fault is not within itself 
but lies within the communication link connection. 
These devices have the capability of reporting an 
35 error condition to an LCSM 3 together with any 
associated data that is normally maintained such as 
traffic counts, error counts and adapter interface 
status conditions that may be reported. 

It Is the responsibility of the LCSM when notified 
40 of a problem by a node 6, to learn what the 
communications link connection configuration Is for 
a given communications link between node 6 and 
node 7 such as in Figure 1. This Information will be 
obtained from the LCCM 4 as will be described later. 
45 The LCSM 3 is responsible for managing its 
assigned link subsystems for a given link connection 
or set of link connections. LCSM 3 receives 
notification of potential problems from using nodes 
such as node 6 In Figure 1. It receives any unique 
50 data from the link LCCs 10 that may be forwarded to 
it by the node 6. The LCSM 3 is the component in the 
system that must send commands eventually to the 
LCCs 10 and which receives their responses. The 
LCSM obtains from the LCCM 4 the present 
55 connection configuration Identifying the elements in 
the given communication link together with the 
addresses of the Individual LCCs 10 with which It will 
communicate. The LCSM does not contain the 
configuration map of the entire link connection. 
60 The LCSM receives commands or Inquiries from 
and responds to requests for tests to be performed 
from the user system or operator 1 in the form of 
generic requests 2 as shown In Figure 1. The 
requests from the operator 1 will be directed to a 
65 given LCSM In response to indication of a problem 
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being reported from a given node 6 which will be 
relayed to the operator and displayed on a screen. 
The operator will determine which LCSM 3 has been 
assigned the management function for determining 
problems within the identified links connected to the 5 
node 6. The operator will issue a generic problem 
determination request to the LCSM 3 that Is 
assigned to managing a given communications link 
and will Identify the target node 7 for problem 
determination. The LCSM 3, In response to these 10 
generic requests, will query the LCCM 4 to deter- 
mine the communications link configurations and 
addresses of devices constituting the link. It will also 
determine what the appropriate protocol or com- 
munication method Is for each Identified specific 15 
LCC 10. The LCSM 3 vAW then generate a sequential 
series of inquiries to implement testing of the 
communications link between nodes 6 and 7 by 
serially issuing diagnostic commands to the individ- 
ual LCCs 10 In turn. It will eventually report either 20 
that a failure has been detected and Isolated to a 
specific LCC 10 or that a failure has been detected 
or has not been Isolated to a specific component or 
that no trouble has indeed been found. 

The LCSM 3 will return a response to the operator 25 
or using system 1 In the form of a generic response 
that has been translated from the device specific 
responses received from the LCCs 10. It may 
indicate that a particular problem has been Isolated 
by a performed probable cause analysis routine 30 
which isolates the error condition to a specific LCC 
10 or to a connection to a specific component within 
its sphere of knowledge. The report to the operator 
or system management program may be employed 
for further analysis or possible rerouting of traffic to 35 
bypass a failed element. The Information may be 
used directly by the operator or may possibly b© 
routed to a higher network management application 
program for further analysis. Because of Its limited 
capabilities, the LCSM 3 is not expected to deter- 40 
mine the probable causes of error for the entire link 
connection that may exist but only for Its own 
assigned LCCs 10. Other LCSMs may be involved In 
determining. probable cause error conditions for still 
other LCCs in a given communications link between 45 
two nodes and the user system or host operator 1 
must be able to send requests for tests to multiple 
LCSMs 3 in such a system configuration In order to 
determine fully what problem Is occurring and which 
element is responsible. 50 

The LCCs 10 typically may be protocol converters, 
computerized branch exchanges, time division 
multiplexers, modems, statistical multiplexers, front 
end line switches, local area network controllers and 
the like. Each link connection component 10 will 55 
perform specific functions that It is capable of 
carrying out at the physical link layer that It 
represents. These functions, which in turn give rise 
to the customary names of the LCCs themselves, 
include: digital to analog signal conversion, typically 60 
performed by modems; line multiplexing, normally 
performed by multiplexors or some switching sys- 
tems; and other functions that effect the physical 
data transmission layer. Each LCC 10 monitors its 
own operational condition for Its own link segment. 65 



At the occurrence of failures, the LCC 10 affected 
may initiate various tests to determine the causes of 
failure or it may merely record them for later analysis 
by another entity. A given LCC 10 may. if It is so 
enabled by its construction, attempt a recovery 
action when a problem Is detected by initiating 
Internal self-tests and/or by notifying its neighbors 
of a problem. It may participate with Its neighbors In 
problem determination procedures which may In- 
clude performing wrap tests or line analysis tests 
such as those carried out typically by some 
"intelligent" modems. Each LCC 10 must be able to 
execute and respond to diagnostic commands 
received from Its assigned managing LCSM 3. The 
commands may cause functions to be performed 
such as self -testing, status checking at Interfaces, 
and collection of various operating parameter set- 
tings for the Individual devices. The specific com- 
mands that may be received from the LCSM 3 will, of 
course, necessarily be In the proper format and/or 
protocol required by the LCC 10. Since various LCCs 
have differing capabilities and may implement differ- 
ent command functions and responses, the physical 
configuration of the individual links between nodes 
served by a given LCSM 3 are maintained in the 
LCCM 4. 

An effective physical "map" of a given communi- 
cations subsystem has a set of links and link 
segments, together with Identification of each of the 
LCCs making up the link, the unique characteristics 
and requirements of each of the LCCs, their 
addresses, and their diagnostic capabilities. All this 
data may be entered manually Into files of data 
maintained by the LCCM 4 for later retrieval and 
response to inquiries. 

An example of how the LCCM 4 can gather 
dynamic configuration data is the IBM 3174 control- 
ler using the Network Asset Management function. 
The IBM 3174 Network Asset Management works as 
follows. When a device attached to the 3174 
powers-on, it automatically passes machine type, 
model and serial number to the 3174. This allows the 
3174 to determine the type of device that is attached 
to It and to physically Identify the de\^ce with a 
unique serial number. The 3174 maintains this data 
with information that identifies the port to which the 
device is attached and an indication that the device 
is currently powered-on. The LCCM 4 can request 
this data from the 3174 and log it in the LCCM's data 
base. This allows the LCCM to automatically gather 
dynamic configuration data without requiring the 
user to manually enter this information into the data 
base. This example has shown that this feature 
allows the LCCM 4 to identify, for example, that 
31 74- A has port 9^3 connected to 3194-B display 
and that the display Is currently powered on. 

Some of the LCCs 10 may be able to dynamically 
establish connections within the link when they are 
activated. Front end line switches, computerized 
branch exchanges and some local area network 
controllers have this capability. This means that the 
physical communication path for a given link seg- 
ment may not be predetermined and stored In the 
data base in a given LCCM 4. The LCCM 4 vAW 
provide an indicator that this Is the type of link 
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segment or link employed since it will have an 
indicator that either static, i.e.. fixed or dynamic, i.e., 
readily changeable connections may be performed 
by a given LCC 10. This allows the LCSM 3 to request 
the specific LCC to determine their current connec- 
tions for each link segment. The LCCM 4 merely 
Informs the LCSM 3 that a dynamic link exists, the 
LCC must be queried to determine what the actual 
connection Is at the present time. 

Summarizing the operation of the overall system 
design Just discussed, it may be seen that the 
structure as described in Figure 1 exists concep- 
tually for each fink connection. At a system level, 
however, the LCSM 3 incorporates processes that 
enable the LCSM to handle problem determination 
for all segments of all the link connections Incorpor- 
ated within a link subsystem or target subsystem 
between a using node 6 and a station 7 as shown in 
Figure 1. This type of design allows the LCSMs 3 to 
be developed to support any type of communica- 
tions protocol or command environment and either 
SNA or non-SNA link connection components may 
thus be easily accommodated. The information that 
flows between the LCSM 3 and the LCCM 4 Is 
designed to provide a generic support capability that 
allows any type of product LCC 10 to be supported. 
Any product unique commands, protocols or re- 
quirements are generated by the LCSM 3 in 
response to the Information It receives regarding the 
physical configuration of the link from the LCCM 4. 
All of the necessary problem isolation and determi- 
nation analysis processes, i.e., a sequential series of 
analyses performed on each LCC 10 in turn, until the 
problem is isolated and identified, will be issued by 
and responded to and the responses analyzed by 
the LCSMs 3 In coordination with the LCCs 10. 

Each of the LCCs 10 must be addressable from its 
corresponding LCSM 3 in order to receive com- 
mands, execute tests, gather data or transmit 
information. The way in which this Is accomplished 
depends upon many factors Including the location of 
the LCSM 3 relative to the given LCC 10 In the 
network, the type of communication path available 
for communication, and the type of data link control 
protocol that Is utilized. The many differences in the 
communication factors mentioned for each LCSM 3 
make it unlikely that a single addressing structure for 
all LCCs 10 may be Implemented. However, within 
the link connection subsystem which exists for a 
given target system between nodes 6 and 7, there 
should be a consistent means of presenting for the 
operator the condition of all the LCCs that make up 
the link. This Is accomplished by the invention which 
IS capable of displaying to the operator the present 
physical connections making up the link together 
with generic responses identifying which element or 
elements have been isolated as being the source of 
a problem. 

The system operator 1 or an automated diagnostic 
program running in a host, is the request control 
node which is able to issue a single diagnostic link 
problem determination command in a generic form 
to an appropriate LCSM 3 and to await a generic 
response from the LCSM 3 without ever having to be 
aware of what the actual link components 10 are. 



what they require in terms of communication specific 
commands, device commands, what capabilities 
they have or what responses they may provide. The 
LCSM 3 that is assigned to managing the link will 
5 obtain this Information from the data files In the 
LCCM 4 and use It to translate the given LCC 
requirements and responses Into an appropriate 
generic response. The LCSM also uses the LCCM 4 
to translate resource names Identifying node A and 
10 station B into Identified target links 8 comprising the 
link segments 9 such as shown in Figure 2. 

Thus, from a mere report of a problem existing at a 
given node such as 6 in Rgure 1, the LCSM 3 will 
relay the problem notification to the using host 
15 operator 1 who will determine which LCSM 3 has the 
task of managing the physical configuration and has 
the capability to diagnose a given target subsystem. 
With this information, the host operator control 
program can Issue a generic command to do a link 
20 problem diagnosis on a given target node. 

The LCSM 3. receiving such a generic request, 
has access to its attached LCCM 4 to determine 
from the node resource names Identified in the 
generic request what the actual Identified target 
25 link 8 must be and what the devices within It are in a 
given configuration. It is also capable of discovering 
what the specific LCC 10 Identifications are, what 
their capabilities are and what their addresses are 
within the system so that it may perform appropriate 
30 diagnostic processes upon them. After performing 
the diagnostic tests, the LCSM 3 can generate an 
appropriate generic response indicating the nature 
of the problem or identifying the source of the 
problem back over the generic interiace 2 to the 
35 user or managing program 1. 

Examples of Operation of the Preferred Embodiment 
This section will describe how the LCSM operates 
as a service system in the context of the preferred 

40 embodiment of the Invention for converting generic 
problem determination requests into appropriate 
commands to be sent to the target system. How It 
receives any data returned from the target system 
and analyzes the results and generates a generic 

45 response back to the user 1 will also be described. 
Prior to giving the example, the Implementation will 
be discussed In terms of the logical and the physical 
link connections that are shown in Figure 3. The 
logical view as shown In Figure 3 Is what the user, 

50 I.e.. system operator or control program 1 knows 
about the logical connections In the system. All tt 
knows is that station A or *node A" Is connected via 
a link, "link 1 " in this example, to an eventual terminal 
or station, "node B". In addition, it will know that 

55 link 1 is managed by a given LCSM. 

The physical view, which is reconstructed event- 
ually by the LCSM 3 using data from the LCCM 4's 
data files and dynamic data from the LCC 10, 
identifies all of the link connection components 

60 together with what ports or connection points or 
terminals are used in making up the actual physical 
connections between node A and node B. It will be 
noted that there are six elements comprising nodes 
A and B and all of the Intermediate LCC devices as 

65 shown In Figure 3. The physical view shown in 
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Figure 3 only indicates that the adapters that exist 
are part of the link connection. In reality, node A, 
LCC-1, LCC-3 and node B may actualiy have muitiple 
adapters that would be used in other link connec- 
tions that are not shown since they form links to 5 
other nodes which are not in question. In the 
example shown in Rgure 3, the physical network is 
assumed to have a bad adapter at port 26 in LCC-3 
that will have to be discovered and diagnosed by the 
LCSM 3 (not shown). The failure of an adapter such 10 
as at port 26 In LCC-3 would prevent activation or 
receipt of communication from node B in the 
physical and logical views shown In Figure 3. 

Problem determination in this example begins as 
shown schematically in Figure 4. Figure 4 con- is 
stitutes both a process flow chart and a schematic of 
the communication process. It Is broken down into 
three horizontal frames or fields of information for 
the overall flow of the process. The user system, or 
operator 1 as designated In Figure 1. is the request 20 
control node which Initially communicates In generic 
request form to the service system 3 operating as an 
Intermediate translation and control facility as desig- 
nated originally in Figure 1. Service system 3, as 
intermediate translation and control facility, issues 25 
devfce-speciftc requests and receives responses 
over an interface 6 connected to the target system 
comprising the links from node 6 to node 7. 

The arrows In Figure 4 show the direction of flow 
of inquiries and responses. Grouped fn vertical 30 
columns beneath the user system 1, service sys- 
tem 3 and target system comprising the compo- 
nents from 6 to 7, are the various requests or 
responses, in the time sequence In which they are 
created In either non-device-spec(fic, i.e., generic 35 
protocol or In devlce-specffic protocol, I.e.. particu- 
j lar protocol and device dependent format, as 
appropriate. 

in the example now being given, it will be assumed 
that a user at station B In Rgure 3 calls a help desk at 40 
the user system operator 1 over a telephone line (not 
shown) to complain that logon to the system, for 
example, cannot be achieved. The help desk 
operator at, user system 1 determines that the 
station B is not active by examining the network 45 
status for station B, available to the operator. After 
determining that there has been no notification 
earlier about this failure, the operator may use the 
LCSM 3 to display the logical paths to station B, This 
will Indicate to the operator that station B Is attached 50 
to Iink-1 and that LCSM-1 is the assigned manager 
for that link, i.e., subsystem. Then, the operator 
sends the first generic command as shown in Figure 
4A. 'Link PD, Unk-1, B". This Indicates that LCSM-1 
should conduct a link problem determination prob- 55 
able cause analysis for the Iink-1 to station B. The 
LCSM 3 receives this request as shown In Rgure 4A 
and sends a corresponding request to its LCCM 4 as 
shown in Figure 1. It asks for the configuration of 
Iink-1 to station B, By this, the LCSM 3 Intends to 60 
determine what the physical communication Inter- 
connection configuration Is between node A and 
station B. 

The LCCM will respond with the infonmation 
shown In Figure 4A describing the physical connec- 65 



tions illustrated previously in Figure 3 for all of the 
LCCs 10 existing between node A and station B. 
Each LCC 10 will be identified by type which will 
indicate to the LCSM what kind of commands will be 
appropriate for each unique LCC, what protocol 
should be employed and what possible responses 
may be received. The LCC name is also given. This 
allows the LCSM to send the unique commands to 
the correct LCC and Indicates to the LCC which 
ports or adapters. If any. should be checked. This 
information from the LCCM also shows the LCSM 
name that identifies the LCSM responsible for the 
management of the given LCCs In the link. It also 
yields an indication of whether a given communica- 
tion physical device LCC happens to have static "S" 
or dynamic "D" connections as shown In Figure 4A. 

In the example now being discussed, the LCSM-1 
is responsible for all of the LCCs In this assumed link 
between a communication adapter A and communi- 
cation adapter B. Interconnections forming the link 
segments are given under the LCC name information 
and It shows that port 20 of communication adapter 
A, which is part of node A. Is connected to port 10 of 
a front end line switch whose output port 20 Is 
connected to a modem LCC-2 whose output Is 
connected to port 12 of an other front end line switch 
whose output port 26 Is connected to modem LCC-4 
which Is connected to the communication adapter 
which is part of station B. Ail of the connections are 
static in this assumed example and this is indicated 
In Rgure 4A. The LCSM-1 Is responsible for 
managing all of the link segments as indicated. This 
is all In response to the link configuration command 
generated by the service system 3 to the LCCM. The 
response contains the information shown in Figure 
4A and Is returned, as the arrow shows, back In the 
direction of the LCSM-1. 

With the physical link connection components 
now identified and known to the LCSM and the 
identity of the managing LCSMs if more than one are 
required, being known, the LCSMs can begin to 
issue appropriate commands to determine If a 
problem can be identified or isolated on this link. The 
LCSM-1 begins the process at the controlling end of 
the link. I.e., that end of the serial connection of 
devices constituting the link that Is nearest to the 
operator In the physical structure of the link. The 
devices are listed sequentially for the assumed 
configurations as shown In the figures, v^lch reflect 
the same order of connections that the physical 
devices exhibit. As shown In Figure 4B, the first 
command Issued by the LCSM 1 is a query status 
command Issued to the node A. port 20. or simply 
adapter 20. The response, as shown in Figure 
4B,[ndicates that the adapter 20 is active but there 
has been no response from station B. This confirms 
that there Is Indeed a problem In the link but the 
response does not Identify the cause of the failure. 

Next, the LCSM 1 will Issue a display connection 
command to the front end line switch. LCC-1, to 
determine the status of the connection between Its 
port 10 and port 20. The response as shown In 
Figure 4B, indicates that the connection is active and 
that no failures have been detected by LCC-1. 
The next component in the physical link between 
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node A and node B is LCC-2 which happens to be a 
modem. The LCSM then issues a modem self-test 
command In appropriate format for LCC-2 to 
respond. The response from LCC 2 indicates that 
the setf-test as commanded has been passed 
successfully and there are no failures detected by 
the LCC-2. 

Next, the LCCM Issues a display connection 
command to the LCC-3 which Is a front end line 
switch and inquires as to the status of the 
connection between a port adapter 12 and port 
adapter 26. or sfmpfy. or port 12 and port 26. The 
response indicates that the connection is inactive 
and that a failure with adapter 26 has been detected 
by the LCC-3. 

There is no need for the LCSM-1 to continue 
testing further, because a problem has at last been 
identified by the LCC-3 and port adapter 26. The 
LCSM 3 will send a reply in a generic form back to 
the operator that identifies LCC-3, port adapter 26 as 
the failing component on link 1 to station B. The 
generic form of the response is as shown in Figure 
4C. The response also includes the hierarchy in the 
physical link interconnection which allows the oper- 
ator to understand how the components are con- 
nected. 

The first example discussed above assumes a 
single LCSM and that intermediate connections of 
the LCCs which It manages are all static ones. A 
second example will now be given In which there are 
both static and dynamic connections involved in the 
subsystem served in a given LCSM. 

The process Is the same as that previously given 
down to the point where the physical link connection 
components have been identified and the LCSM can 
start issuing the appropriate commands to deter- 
mine if the problem can be Identified and/or isolated 
on the link. Figure 5A shows the response from the 
LCCM In response to the link configuration request, 
■UNK CONFIG. LINK-1. B* given by the LCSM-1 to 
the LCCM. 

In Figure 5A. the first component Identified by the 
LCCM in the link Is the communications adapter, so 
LCSM-1 issues a communication adapter query 
status command to determine the status of adapter 
20. This is the same type of command for status 
inquiry as previously discussed with relationship to 
Figure 4B. A response in this case Indicates that the 
adapter is acth^e but there Is no response from 
station B. This confirms that there Is a problem, as 
was the case with the example previously given, but 
does not identify the causes of failure. 

Next, LCSM-1 wHI issue a display connection 
command to the front end line switch, LCC-1 to 
determine the status of the dynamic connection to 
which its adapter 10 is currently connected. The 
response will indicate that adapter 10 is connected 
to adapter 20 and that the connection is active and 
no failures have been detected by LCC-1. In the path 
as Identified In the LCCM's response to the the 
LCSM. the next component In the path is LCC 2. 
which is a modem. The LCSM therefore issues a 
modem self-test command to the LCC 2 modem. 
The response from the modem indicates that the 
self-test was passed and no failures have been 



detected by the modem. 

Next the LCSM will issue a display connection 
command to the second front end line switch, 
LCC-3, to determine the status of the dynamic 
5 connection to which adapter 12 Is connected. The 
response will Indicate that the connection Is Inactive, 
that it had been connected to adapter 26. and that a 
failure with adapter 26 has been detected by the LCC 
3. At this point there Is no need for the LCSM to 
10 continue testing; a problem has been Identified by 
LCC-3 with adapter 26. The LCSM will send a reply to 
the original generic link problem determination 
command from the user that will identify LCC-3. 
adapter 26 as the failing component on link 1 to 
15 station B. 

Next, an example using two LCSMs and both 
static and dynamic connections will be given. The 
basic problem determination procedure follows as 
with the previous two examples through the section 
20 where the LCSM has Issued the link configuration 
request to the LCCM and has received the response 
Indicating the present physical connections In the 
given link. In the example, Figure 6A .shows the 
configuration that Is assumed to exist for this 
2S problem. The first component identified in this 
linkage Is the communication adapter, so the 
LCSM-1 Issues the communication adapter Inquiry 
status command to determine the status of adapter 
20. The response In this case indicates that the 
30 adapter is active but there has been no response 
from station B. This confirms that there Is a problem 
but does not Identify the cause of the failure. 

Next, the LCSM 1 will Issue a display connection 
command to the LCC-1 which Is a front end line 
S5 switch to determine the status of the dynamic 
connection that adapter 10 provides. The response 
will Indicate that adapter 10 is connected to adapter 
20 and that the connection Is active and no failures 
have been detected by the LCC 1. 
40 The next component In the path is LCC-2 which is 
a modem as previously indicated. This modem, 
however, is assigned to LCSM-2 for management 
purposes. Thus, LCSM-1 does not Issue commands 
to the LCC-2 but instead, Issues the generic 
45 request, link problem determination command to the 
LCSM-2 and Indicates that the problem determina- 
tion should be conducted for the LCC-2. LCSM-2 
receives this generic request and sends a link 
configuration request to the LCCM which serves It to 
50 determine the physical configuration for the LCC-2. 
The LCCM serving the LCSM 2 will give a response 
that includes an indication of the current physical 
connections for LCC-2. This will Indicate that It Is a 
modem and that there are no other LCCs that need 
55 to be tested. With the physical identification of 
LCC-2 completed, the LCSM-2 can Issue the modem 
self-test command to the LCC-2 as LCSM-1 would 
have had It been assigned the task of managing 
LCC-2. The response from LCC-2 Indicates the 
60 self-test Is passed and there are no failures 
detected. LCSM-2 will then send a reply In a generic 
format back to the LCSM-1 that indicates that no 
failure was detected. 

Next, the LCSM-1 will issue a display connection 
65 command to the LCC-3 which Is within its control to 
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determine the status of the dynamic connection to 
which adapter 12 is connected. The response will 
indicate that the connection is inactive but that ft was 
connected to adapter 26 and that a failure with 
adapter 26 has been detected by LCC-3. The 
example concludes at this point since there is no 
need for the LCSM to continue testing. The probienn 
has been identified with LCC 3 adapter 26. 

In the example just given, the LCSI^ Implementa- 
tions show that one or more LCSMs might be 
assigned "ownership" of the various LCCs in the 
target system. In reality, this Is often the case and, In 
fact. Individual LCCs can be "owned" by many 
different LCSMs and the LCSMs themselves may be 
interconnected In a layered structure or horizontally 
in equal priority as peer connected. Nested, or 
layer-connected LCSMs provide a system in which 
the user may only know that one LCSM actually is on 
a link. The user would send the generic requests to 
that LCSM to perform link problem determinations. 
The LCSM-1 would make a request to its subservient 
nested LCSMs of which It would be aware but which 
the user would not know existed. If the Individual 
LCC*s characteristics finally identified from the 
configuration commands Issued by the LCSM to the 
LCCM showed that various LCSMs were assigned to 
the physical link LCCs, then the LCSM-1 would use 
the generic commands to ask the subservient 
LCSM-2 or -3 to perform link problem determination 
routines and to send the results back to LCSM-1. 
This structure allows many components and/or 
LCSMs to be added to given links without requiring 
the user system 1 to be aware of the changes or 
even to require all LCSMs to be aware of the 
additional component so long as the highest nested 
LCSM has a LCCM that is aware of the changes. 
' Figure 7 shows the concept of nested LCSMs which, 
from the user system, provide the appearance of a 
single LCSM-1, since the user will not be aware that 
any subservient LCSM-2 or any further LCSMs exist. 
User system 1 will thus send its link problem 
determination generic commands to the first LCSM, 
LCSM-1. LCSM-1 which is aware of the other 
LCSMs, following the receipt of information from Its 
own generic link configuration request to its at- 
tached LCCM 4, will know that some of the LCCs are 
identified vwth a different LCSM name, for example 
the LCSM-2, LCSM-1 will therefore send appropriate 
commands for the affected LCCs to ask LCSM-2 to 
perform link problem determination in generic 
request format and to send the results In generic 
format back to the LCSM-1. This type of structure 
allows components and LCSMs to be added to the 
link without ever requiring user system 1 or even all 
of the LCSMs to be aware of the additionaJ changes 
or components. In the example shown In Figure 7, 
LCSM-1 is responsible for the using node A. LCC-2 
and LCC-4. However, LCSM-2 is responsible for the 
LCC-1, LCC-3 and station B. Both LCSM-1 and -2 
are necessary to manage the complete target 
system between node A and node B as shown. 

Peer connected to LCSMs may be shown In the 
example illustrated In Rgure 8. In Figure 8, two user 
systems 1 exist, although one may not be aware of 
the other. In addition, two service systems. LCSM-1 



and LCSM-2, exist, although each user system may 
not be aware of the other subservient LCSM to 
which it is not directly connected. In short, when 
LCSMs are peer connected as in Figure 8, there may 
5 be multiple user systems that are trying to do 
problem determination on the same target system. 
These user systems may not be aware of each 
other's existence or that there are multiple LCSMs 
Involved with the link connection. The LCSMs in 
10 Rgure 8 will use generic commands to communicate 
between one another and would send the results to 
their respective user systems making the problem 
determination requests. Peer connected LCSMs are 
shown with LCSM-1 being responsible for the using 
75 node A and LCC-1 while LCSM-2 Is responsible for 
using node B and the LCC-2. Again, two separate 
LCSMs are jointly responsible for the overall man- 
agement of the target system link between node A 
and node B. To issue commands, execute tests or 
20 gather data, the generic command structure bet- 
ween user systems 1 and the service systems 3 or 
between service systems 3 has been described 
above. The same structure is also used between 
LCSMs for communication or between the LCSM 
25 and their attached LCCMs as previously defined. 
Figure 9 illustrates the generic command or reply 
format which permits uniform communication 
among users and LCSMs or between LCSMs and 
other LCSMs and LCCMs. 
30 The format for communications begins with a 
header 11 followed by a unique command field 12 
which is followed by a field 13 comprising one or 
more parameters Identifying conditions associated 
with the given commands in field 12. Following are 
35 descriptions of some commands and their functions 
that have been designed to support the interchange 
between the user system 1 and the service system 3 
or between separate sendee systems and other 
service systems or the LCCMs associated therewith. 
40 First there Is a "send message to operator" 
command. A message will be generated with a 
unique header that identifies a generic command 
message. The unique header is the same In all 
communications among sending and receiving 
45 generic message and command devices In the 
system. The function of this message, "message to 
operator". Is to provide messages among system 
operators using the system. It Is used as a means of 
communication between operators working on the 
50 same problem but who may be remote from one 
another. For example, an operator at a given user 
system 1 and another operator at a service system 3 
may exchange messages in this fashion. The 
command Includes as parameters after the specific 
55 send message command In the command field 12. a 
name list, a short message, a qualified message, 
message identifications, replacement text and user 
text messages. The types of messages would be 
identified In the field 13 by the parameters specified. 
60 Numerous other parameters for other types of 
messages may easily be envisioned, although only a 
few specific types of messages have been identified. 

The same message format as shown in Figure 9 
may be used for a variety of commands, the unique 
$5 generic command header in field 11 being the same 
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in all cases, but the code point selected for the 
unique command in field 12 being arbitrarily estab- 
lished as user system management dictates. 

Another command would be the run command 
and reply. This will Initiate a request to execute a 5 
command by some target system manager. This 
command Is used by the LCSMs to send product 
specific LCC commands to other LCSMs. The 
sender and receiver must understand how to 
support these non-generic command formats. This 10 
command provides a transportation envelope for 
passing new commands and responses between 
operators and applications and allows the network 
operator a vehicle to issue requests for having 
commands executed by specific LCSMs. The conri- 15 
mands to be issued by the LCSM in executing this 
command are the specific subsystem device-spe- 
cific commands used to operate the subsystem 
under the control of a given LCSM. The response 
from an LCSM back to the system operator Is the 20 
same format as the run command but includes In the 
parameter field 13 replies In the form of reply counts, 
procedure Identrficattons, data sensing information, 
various messages and/or text. 

The link problem determination command and 25 
reply format was alluded to in the several examples 
above. This command initiates the analysis of the 
status of the various LCCs managed by a specific 
LCSM. The command allows the problem determina- 
tion to be performed on any link without having the 30 
operator understand the location of the link connec- 
tion components or even to know what type of 
components are there or what commands they are 
capable of supporting. The reply uses the same 
format and Includes specific identifications for: No 35 
failure detected; Failure isolated at LCC; Failure 
Isolated at segment: Failure outside scope of this 
LCSM (upstream); Failure outside scope of LCSM 
within Identified link segment; or Failure outside 
scope of LCSM on other side of link segment 40 
(downstream). 

Another command Is the link data command and 
reply command. It requests control data or, the 
statistics or any error data held by or stored for the 
various LCCs belonging to a specific target system. 45 

Another command Is the link test command and 
reply. This may be used to set the LCCs into test 
mode and request that the LCCs specific test 
results be reported. This command allows the 
testing by the operator of any link without having any 50 
understanding of the location of the link connection 
components or what type of devices exist there or 
what commands they support. 

Yet another command that was referred to in the 
examples above Is the link configuration command 55 
and reply. This is an inquiry from the LCSM to the link 
configuration connection manager, LCCM 4 in 
Figure 1. It inquires as to what the component 
resources are and what their status may be at a 
given time. It allows the requester to determine the 60 
physical connections making up a link by Identifying 
the LCC types, names and identity of the managing 
LCSMs therefor as well as to determine whether the 
connection is a static or dynamic one. 
It may be observed that the overall structure as 65 



shown In Figure 1 provides a system and method of 
communication and a process for problem Isolation 
that provides an operator with the capability of 
requiring tests on physically specific link connection 
components without ever knowing what compo- 
nents exist or where they exist within the system 
since the determination can be conducted for a 
given target system link without the operator's 
knowing the makeup thereof. Therefore, while the 
invention has been described with respect to a 
preferred embodiment and several Illustrative exam- 
ples of usage thereof, it will be apparent to those of 
skill in the art that various implementations of the 
invention may be envisioned that would relocate the 
functional capacities of the user system, the LCSM, 
the LCCM and the various LCCs and various peer or 
nested or combined peer and nested hybrid configu- 
rations without departing from the spirit and scope 
of the invention. Additionally, the functions of the 
LCSM and LCCM and/or the user system may all be 
met by application programs themselves having little 
or no need for human Interaction Involved In their 
use. Therefore, what Is described and what is 
Intended to be protected by Letters Patent Is set 
forth in the claims which follow by way of exaniple 
only and not as limitation. 



Claims 

1. A method of Isolating and diagnosing 
problem conditions In a data communications 
network link, comprising steps of : 

issuing from a request control node, a generic 
non-device-specific request for problem deter- 
mination to be performed on an identified 
communication link connected to an Identified 
target node, 

receiving on said data communications network 
said request at an Intermediate control and 
translation facility and, responsive to said 
request, issuing from said Intermediate transla- 
tion and control facility at least one device-spe- 
cific problem determination command on said 
communications link connected to said inter- 
mediate translation and control facility and to 
said target node. 

receiving on said communications link con- 
nected to said target node at said Intermediate 
control and translation facility at least one 
device-specific response from a device on said 
communication link, and, 
responsive to said receipt of said device-spe- 
cific response either Issuing on said communi- 
cations link further device-specific commands 
or issuing on said data communications net- 
work, non-device-specific problem identifica- 
tion diagnoses as responses to said non-de- 
vlce-speciflc generic request from said request 
control node. 

2. A method as described In Claim 1, 
wherein : 

said issuing of said device-specific problem 
determination commands is conducted serially 
by order of device interconnection in said 
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communication link beginning with the device in 
said link nearest to said intermediate control 
and translation facility. 

3. A method as described In Claim 1 or 2. 
further comprising a step at said intermediate 
translation and control facility of : 

retrieving communication link physical configu- 
ration data identifying the physical components 
of said Identified communication link to said 
Identified target node together with the physical 
characteristics of said components thereof that 
currently make up said communication link to 
said target node. 

4. A method as described in Claim 1 , 2 or 3 for 
peer or nested interconnection further compris- 
ing steps of : 

Identifying at said Intermediate translation and 
control facility that said target node is served by 
another said intermediate translation and con- 
trol facility; and 

refssuing from said intermediate translation and 
control facility a general, non-device-specific 
request to said another Intermediate translation 
and control facility to prompt issuance there- 
from of said device-specific commands on said 
data communication link. 

5. A method as described In Claim 4, In which 
said generic, non-device-speclflc commands 
include a preliminary unique command ident- 
ifying header, a command field and at least one 
command parameter identifying field. 

6. Apparatus for diagnosing and controlling 
failure or problem conditions In a data com- 
munication network link, comprising : 

a request control facility having means for 
Issuing generic, hon-devlce-speclfic requests 
on said data communication network for prob- 
lem determination to be performed on an 
Identified communication link connected to an 
Identified target node; 

an intermediate translation and control facility 
connected to said communication network for 
receiving said generic, non-device-specific re- 
quests , and responsive thereto, for issuing 
therefrom at least one device-specific problem 
determination command to a device on said 
communication link to said target node; and 
means at said Intermediate translation and 
control facility for receiving a device-specific 
response from said device on said communica- 
tions link and responsive thereto, for either 
Issuing further device-specific commands on 
said communication link or for Issuing generic, 
non-device-specific problem Identification diag- 
noses responses to said requesting control 
means. 

7. Apparatus as described In Claim 6, 
wherein : 

said intermediate translation and control facility 
Issues said device-specific commands serially 
be device by beginning with the device In said 
communications link at the end of said link 
nearest to said intermediate translation and 
control facility. 

8. Apparatus as described in Claim 6 or 7, 
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further including means for storing physical 
configuration data link component characteris- 
tics, identities and locations making up said 
communication link to said target node. 

9. Apparatus as described in Claim 6, 7 or 8, 
further comprising : 

means at said intermediate trahslatlon and 
control facility for determining that said target 
node is served by another said intermediate 
translation and control facility and reissuing 
said general, non-device-specific requests to 
said another Intermediate translation arid con- 
trol facility for Issuance therefrom of said 
device-specific commands on said communica- 
tion link to said target node. 
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